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Abstract: 

Truth  maintenance  systems  have  been  used  in  several  recent  problem  solving  systems  to  record 
justifications  for  deduced  assertions,  to  track  down  the  assumptions  which  underlie  contradictions  when  they 
arise,  and  to  incrementally  modify  asscrtional  data  structures  when  assumptions  arc  retracted.  A  IMS 
algorithm  is  described  here  that  is  substantially  different  from  previous  systems.  Hi  is  algorithm  performs 
deduction  in  traditional  propositional  logic  in  such  a  way  that  the  premise  set  from  which  deduction  is  being 
done  can  be  easily  manipulated.  A  novel  approach  is  also  taken  to  the  role  of  a  I  MS  in  larger  deductive 
systems.  In  this  approach  die  I  MS  performs  all  propositional  deduction  in  a  uniform  manner  while  the  larger 
system  is  responsible  for  controlling  the  instantiation  of  universally  quantified  formulae  and  axiom  schemas. 
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1.  INTRODUCTION 

Recently  there  has  been  some  interest  in  dependency  structures  which  can  be  used  in  reasoning  and 
problem  solving  systems.  Such  dependency  structures  can  be  used  to  make  reasoning  systems  more 
incremental  during  retraction  and  backtracking  and  better  able  to  explain  their  results  [Kikes  75|Stallman  & 
Sussman  77JShrobc  77].  'Ibis  has  given  rise  to  special  purpose  systems  for  handling  logical  dependencies, 
and  even  the  notion  of  non-monotonic  logics,  i.c.  logics  in  which  larger  premise  sets  can  have  fewer  valid 
consequences  [Doyle  77RReitcr  79[.  I  have  borrowed  the  term  truth  maintenance  system  (TMS)  from  Jon 
Doyle  to  describe  any  system  with  the  following  four  characteristics: 

a)  It  performs  some  form  of  propositional  deduction  from  a  set  of  premises. 

b)  It  maintains  justifications  and  explains  the  results  of  its  deductions. 

c)  It  incrementally  updates  its  beliefs  when  premises  arc  added  or  removed. 

d)  It  docs  dependency  directed  backtracking;  i.c.  when  a  contradiction  arises  it  uses  the 

recorded  justifications  to  track  down  the  premises  which  underlie  that  contradiction. 

Two  major  points  about  truth  maintenance  are  made  here.  First  a  TMS  can  be  based  on  deduction 
in  traditional  propositional  logic.  Second,  a  TMS  can  be  used  as  an  active  deductive  component  of  general 
deductive  systems. 

The  TMS  algorithm  described  here  is  based  on  "propositional  constraint  propagation"  which  was 
originally  described,  in  essence,  by  Davis  and  Putnam  [Davis  &  Putnam  60],  This  technique  is  related  to  the 
algebraic  constraint  propagation  of  Sussman  [dc  Klccr  &  Sussman  78)  and  the  graph  labeling  algorithms  of 
Walt/  [Walt/  72).  Section  two  describes  the  details  of  this  technique,  and  the  way  in  which  the  basic  TMS 
functions  listed  above  can  be  integrated  into  it 

The  ability  to  incrementally  manipulate  the  premise  set  allows  a  great  deal  of  flexibility. 
Assumptions  can  be  made  which  can  later  be  retracted  if  they  arc  found  to  support  contradictions.  Some 
basic  techniques  for  controlling  assumptions,  and  for  controlling  the  premise  set  in  general,  arc  described  in 
chapter  three. 

The  TMS  can  be  used  to  perform  all  propositional  deduction  in  a  general  deduction  framework.  The 
primary  aspect  of  general  deduction  which  cannot  be  performed  by  a  TMS  is  the  instantiation  of  quantified 
formula  and  axiom  schema.  Ilic  position  is  taken  here  that  those  problems  which  arc  of  a  purely  propositional 
nature  can  be  solved  to  such  a  degree  that  the  only  difficult  issues  remaining  in  automated  deduction  involve 
the  control  of  instantiation. 
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2.THETMS 

The  TMS  described  here  operates  on  an  asscrtional  data  base.  Traditionally  an  asscrtional  data  base 
has  been  cither  a  simple  set  of  assertions  or  a  collection  of  "contexts"  each  of  which  could  be  thought  of  as  a 
set  of  assertions  [Hewitt  72)  [McDermott  74).  The  TMS  algorithm  developed  here  operates  on  a  data  base  in 
which  assertions  arc  assigned  to  one  of  die  three  states,  "true",  "false”,  and  "unknown".  It  is  possible  to  map 
Uiis  data  base  to  a  simple  set  of  assertions  by  first  taking  the  set  of  assertions  which  arc  "true"  and  then  adding 
the  negations  of  the  assertions  which  arc  "false".  Thus  the  data  base  can  be  simultaneously  viewed  as  a 
traditional  set  of  assertions,  and  as  an  assignment  of  die  states  "true",  "false",  and  "unknown"  to 
non-truditional  assertions. 

These  different  outlooks  on  the  asscrtional  data  base  can  lead  to  some  confusion  in  terminology.  For 
example  suppose  one  wants  to  assert  that  Fred  is  not  a  fish.  One  can  speak  of  "adding  the  premise"  (not  (fish 
Fred)).  But  diis  act  of  "adding  a  premise”  may  actually  involve  putting  die  assertion  (fish  Fred)  in  a  "false” 
state.  Ihe  remainder  of  this  paper  relics  on  context  for  die  proper  interpretation  of  such  terminology. 

Iherc  arc  four  primary  functions  performed  by  diis  I  MS.  First  it  performs  propositional  deduction 
via  a  deduction  technique  which  is  termed  here  "propositional  constraint  propagation".  Second  it  generates 
justifications  for  each  deduced  truth  value.  Next  it  is  capable  of  incrementally  updating  the  data  base  when 
premises  are  removed.  Finally  it  is  capable  of  dependency  directed  backtnicking.  The  technique  used  in 
backtracking  is  easily  extended  to  a  refutation  mechanism  which  adds  to  the  deductive  power  of  the  TMS. 

2.1.  Propositional  Constraint  Propagation 

In  general  a  constraint  propagation  system  has  a  set  of  "cells”  which  can  take  on  values,  and  a  set  of 
"constraints"  which  constrain  those  values.  Whenever  a  new  value  follows  from  the  previously  determined 
values  and  a  single  constraint,  this  value  is  deduced.  In  what  will  be  tenned  "simple"  constraint  propagation 
these  arc  the  only  deductions  which  are  made.  Constraint  propagation  terminates  when  there  arc  no  further 
deductions  which  can  be  made  from  single  constraints,  and  the  set  of  constraints  is  said  to  be  "relaxed".  If  the 
number  of  values  which  can  be  determined  by  a  single  constraint  is  bounded  then  this  process  can  take  no 
longer  than  linear  time  in  the  number  of  constraints. 

In  propositional  constraint  propagation  the  assertions  in  the  data  base  are  viewed  as  cells  or  ’TMS 
nodes"  which  can  take  on  one  of  the  values  "true"  or  "false".  All  logical  relations  (constraints)  in  the  TMS 
take  the  form  of  disjunctive  clauses  such  as  (v  (p  .  false)  (q  .  true)).  This  constraint  says  that  is  impossible  for 
both  P  to  be  true  and  Q  to  be  false.  Therefore  whenever  P  is  true  the  constraint  could  be  used  to  deduce  that 
Q  must  be  true.  Likewise  whenever  Q  is  false  the  constraint  could  be  used  to  deduce  that  P  must  be  false.  As 
in  the  case  of  general  constraint  propagation,  the  TMS  will  deduce  any  truth  value  which  follows  from  the 
truth  values  already  present  and  a  single  constraint  (clause).  This  process  is  iterated  until  the  constraint  set  is 
relaxed.  It  is  possible  to  add  premises  and  constraints  incrementally  and  the  I  MS  has  no  difficulty  performing 
the  additional  deduction  needed  to  relax  die  constraint  set. 
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Tabic  1.  Axioms  for  Propositional  Logic 


or  (v  ((or  p  q)  .  falsa) (p  .  trua) (q  .  trua)) 

(v  ((or  p  q)  .  trua)  (p  .  falsa)) 

(v  ((or  p  q)  .  trua)  (q  .  falsa)) 

and  (v ((and  p  q)  .  trua) (p  .  falsa) (q  .  falsa)) 

(v  ((and  p  q)  .  falsa)  (p  .  trua)) 

(v ((and  p  q)  .  falsa) (q  .  trua)) 

->  (v  ((->  p  q)  .  falsa)  (p  .  falsa)  (q  .  trua)) 

(v  ((->  p  q)  .  trua)  (p  .  trua)) 

(v  ((->  p  q)  .  trua)  (q  .  falsa)) 

not  (v  ((not  p)  .  trua)  (p  .trua)) 

(v  ((not  p)  .  falsa) (p  .  falsa)) 


It  is  important  to  note  that  not  all  deductions  which  follow  logically  from  a  set  of  constraints  are 
deduced  by  this  algorithm.  For  example,  p  follows  from  the  two  constraints,  (v  (p  .  true)  (q  .  true))  and  (v  (p . 
true)  (q  .  false)).  However  the  system  can  make  no  deductions  from  these  constraints.  Some  of  the 
implications  of  this  observation,  and  some  ways  of  dealing  with  such  situations  arc  discussed  in  later  sections 
of  this  chapter. 

Ihc  TMS  performs  propositional  deduction  from  a  set  of  propositional  premises.  ITicsc  premises 
take  the  form  of  assignments  of  truth  values  to  assertions.  ITic  constraints  in  the  IMS  arc  derived  from  basic 
axioms  of  propositional  logic.  Kach  of  the  logical  symbols  or,  and.  ->,  and  not  has  an  associated  axiom  set 
which  can  be  used  to  generate  clausal  constraints.  The  axioms  for  each  of  these  symbols  arc  given  in  table  1. 
For  each  assertion  in  the  data  base  which  involves  one  of  the  basic  logical  symbols  the  axioms  for  that  symbol 
are  used  to  generate  the  clausal  constraints  relevant  to  that  assertion,  in  reading  these  axioms  it  is  important 
to  remember  that  each  clause  gives  a  means  by  which  each  term  in  that  clause  might  be  deduced. 

To  get  some  feel  for  the  deductive  power  of  a  propositional  constraint  propagator  some  examples 
need  be  developed.  For  convenience  the  scenarios  use  an  assert  function  which  takes  an  assertion 


Scenario  I.  A  Deduction  Involving  or 

(aaaart  '(not  r)) 

(NOT  ft) 

(anort  '(or  r  a)) 

(Oft  ft  S) 

(truth  ’a) 

TRUE 
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represented  as  an  s-expression  and  gives  the  corresponding  TMS  node  a  truth  value  of  "true"  as  a  premise.  In 
the  scenarios  things  typed  by  the  user  will  appear  in  lower  case  while  responses  by  the  system  will  appear  in 
uppercase. 

To  understand  scenario  I  consider  the  constraints  which  arc  created  when  the  assertions  (or  r  s)  and 
(not  r)  arc  created.  Among  the  constraints  generated  for  (not  r)  is  the  clause  (v  ((not  r) .  false)  (r  .  false)). 
When  (not  r)  is  made  true  r  is  deduced  to  be  false  via  this  constraint.  In  general  the  axioms  for  not  guarantee 
that  an  assertion  and  its  negation  always  have  opposite  truth  values.  Among  the  constraints  generated  for  (or 
r  s)  is  the  clause  (v  ((or  r  s) .  false)  (r .  true)  (s  .  true)).  When  (or  r  s)  is  made  true  this  clause  is  used  to  deduce 
that  s  must  be  true. 

In  general  there  arc  three  assertions  which  are  relevant  to  an  application  of  one  of  the  logical 
symbols  and,  or.  and  ->.  The  first  assertion  is  the  application  itself,  such  as  (or  r  s).  The  second  two  assertions 
arc  the  arguments  in  this  assertion,  such  as  r  and  s.  The  propositional  axioms  guarantee  that  whenever  a  truth 
value  of  one  of  these  assertions  can  be  deduced  from  truth  values  assigned  to  the  other  two,  that  deduction  is 
made  by  the  TMS.  Scenario  2  is  another  example  of  the  type  of  deduction  which  is  carried  out  by  the  I  MS. 

2.2.  Justifications 

Whenever  a  deduction  is  made  a  justification  for  the  deduced  value  is  constructed.  F.vcry  deduction 
made  by  the  I  MS  involves  only  a  single  clause,  along  with  the  truth  values  of  assertions  in  that  clause.  Thus 
the  clause  involved  in  a  deduction  carries  all  the  information  needed  for  a  justification.  Therefore  in  the  TMS 
a  justification  for  a  deduced  truth  value  is  simply  a  pointer  to  the  clause  which  was  used  to  deduce  that  value. 

F.vcry  deduced  truth  value  can  be  associated  with  a  set  of  supporting  truth  values  via  its  justification. 
If  any  of  these  values  were  deduced  by  the  system  (i.e.  they  arc  not  premises)  then  they  will  in  turn  have 
supporting  values.  By  searching  down  such  support  structures  it  is  always  possible  to  find  the  set  of  premises 
from  which  any  deduced  value  was  derived.  A  query  function,  why,  has  been  defined  to  give  die  set  of 
supporting  values  for  any  deduced  truth  value.  Scenario  3  gives  an  example  of  the  use  of  why  and  figure  1 
diagrams  the  support  structure  involved,  'llic  function  why  can  take  a  numeric  argument  which  refers  to  the 


Scenario  2.  A  Deduction  Involving  •> 

(assert  ’(->  r  «)) 

(*>  *  S) 

(assert  ’(->  s  t ) ) 

('»  S  T) 

(assert  ’(not  t ) ) 

(•OT  T) 

(trutn  T) 

FALSE 
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Scenario  3.  An  example  of  the  use  of  why 


(assert  '(->  r  s ) ) 

(->  «  S) 

(assert  '(->  s  t ) ) 

(*>  S  T) 

(assert  '(not  t)) 

(MOT  T) 

(ehy  'r) 

( ( R  IS  FALSE  FROM) 

(1  (->  R  S)  IS  TRUE) 

(2  S  IS  FALSE)) 

(why  2) 

((S  IS  FALSE  FROM) 

(1  (->  S  T)  IS  TRUE) 

(2  T  IS  FALSE)) 

(why  Z) 

((T  IS  FALSE  FROM) 

(1  (MOT  T)  IS  TRUE)) 

(WHY  1) 

((NOT  T)  IS  TRUE  AS  A  PREMISE) 


Fig.  I.  The  Support  Structure  for  Scenario  3 
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assertion  which  was  associated  with  that  number  in  the  last  explanation  given. 

Premises  are  distinguished  in  the  system  as  truth  values  with  no  justification.  At  any  time  the  user  of 
the  I  MS  may  add  any  truth  value  as  a  premise  other  titan  the  opposite  of  a  truth  value  already  present  as  a 
premise.  If  the  added  premise  is  a  truth  value  which  was  already  deduced  by  the  system  then  the  justification 
for  the  deduced  value  is  simply  removed.  If  the  added  truth  value  is  the  opposite  of  one  already  deduced  by 
the  system  then  the  deduced  value  is  retracted  and  the  opposite  value  is  assigned.  The  details  of  how  this  is 
done  and  how  the  resulting  contradiction  is  handled  arc  discussed  in  the  next  two  sections. 

It  is  important  that  support  structures  be  “well  founded".  That  is  to  say  that  no  deduced  truth  value 
can  depend  on  itself.  For  the  deduction  process  as  defined  so  far  this  is  guaranteed  since  justifications  are 
determined  at  the  instant  at  which  a  value  is  deduced  and  no  value  in  the  system  yet  depends  on  the  deduced 
value.  However  some  care  need  be  taken  during  incremental  retraction  to  see  that  supports  remain  well 
founded.  1'his  will  be  discussed  in  the  next  section. 

2.3.  Retraction 

One  of  the  fundamental  operations  of  truth  maintenance  is  incrementally  updating  the  asscitional 
data  base  when  premises  are  retracted,  This  should  be  done  in  such  a  way  that  all  deductions  arc  made  which 
would  have  been  made  if  the  system  had  started  with  the  new  premise  set,  and  that  every  deduced  truth  value 
(every  one  which  is  not  a  premise)  has  a  well  founded  support  structure.  There  arc  two  stages  in  the  retraction 
process.  First  all  deduced  truth  values  which  depended  on  the  removed  premise  arc  removed.  This  is  done  by 
checking  all  clauses  which  contain  any  assertion  whose  truth  value  was  retracted  to  see  if  it  now  invalidly 
supports  some  other  value.  If  it  docs  then  that  value  is  recursively  retracted.  The  second  phase  of  the 
retraction  process  involves  checking  all  assertions  which  had  truth  values  retracted  to  see  if  some  value  can  be 
deduced  for  them  in  some  other  way.  Because  all  deduction  is  done  in  an  environment  in  which  all 
justifications  arc  valid  and  well  founded,  the  justifications  resulting  from  any  deduction  must  be  valid  and 
well  founded. 

Retraction  is  also  involved  when  the  user  adds  a  premise  which  the  system  has  already  deduced  to 
be  false;  i.c.  the  user  wishes  to  assign  a  truth  value  to  an  assertion  as  a  premise  but  the  system  has  already 
deduced  the  opposite  value  for  that  assertion.  In  this  ease  phase  one  of  the  retraction  process  is  applied  to  the 
deduced  truth  value  so  that  the  deduced  value  is  removed  along  with  all  of  its  consequences.  Then  the  truth 
value  being  given  that  assertion  as  a  premise  is  added.  Finally  phase  two  of  the  retraction  process  is  applied  to 
perform  any  deduction  which  can  done  via  standard  propositional  constraint  propagation.  Of  course  the  data 
base  will  then  be  in  a  state  of  contradiction,  which  is  discussed  in  the  next  section. 
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2.4.  Backtracking  and  Refutation 

The  term  "contradiction"  will  be  used  here  to  refer  to  a  clause  in  the  TMS  all  of  whose  terms  arc 
false.  For  example  the  clause  (v  (p  .  false)  (q  .  true))  would  be  a  contradiction  in  any  situation  in  which  p  was 
true  and  q  was  false.  Contradictions  can  come  into  existence  at  any  time  during  deduction  or  die  addition  of 
premises.  The  premise  set  underlying  a  contradiction  is  the  union  of  the  premise  sets  for  die  truth  values 
directly  involved.  To  ensure  that  backtracking  docs  not  interfere  with  deduction  or  retraction,  all  processing 
of  contradictions  is  done  outside  any  of  these  processes.  When  contradictions  arise  die  system  asks  the  user 
(or  the  system  using  die  I  MS)  to  choose  one  of  the  premises  underlying  the  contradiction  for  retraction.  Ihis 
process  has  been  termed  "dependency  directed  backtracking"  [Stallman  &  Sussman  77]  and  a  simple  example 
is  given  in  scenario  4. 

When  a  premise  which  underlies  a  contradiction  is  retracted  it  is  important  diat  its  negation  be 
deduced  to  prevent  a  re-occurrence  of  the  same  contradiction  at  a  later  time.  This  can  sometimes  be  done  by 
the  propositional  constraint  propagation  algoriditn  already  discussed.  However  dicrc  are  eases  where  this  is 
not  so.  For  example  consider  what  happens  in  scenario  5.  Hie  assertion  c  logically  follows  from  the  assertions 
(->  a  c).  (->  l>  c),  and  (or  a  b).  but  the  system  is  incapable  of  deducing  diis.  When  (not  c)  is  asserted  the  system 
deduces  that  both  a  and  b  must  be  false  which  leads  to  the  clause  (v  ((or  a  h)  .  false)  (a  .  true)  (b  .  true)) 
becoming  a  contradiction  (a  clause  involving  one  of  the  the  implications  could  just  as  easily  become  a 
contradiction  if  deduction  was  done  in  a  different  order).  The  assertion  (not  c)  is  one  of  the  premises 
underlying  this  contradiction.  Without  some  additional  mechanism  however  the  system  is  incapable  of 


Scenario  4.  A  Simple  Kxample  of  Backtracking 


(assert  ’(or  r  *)) 

(OB  R  S) 

(assert  ’(not  r)) 

(MOT  R) 

(assert  '(not  s ) ) 

((THERE  IS  A  CONTRADICTION  FRO* 

((OR  R  S)  BEING  TRUE) 

(R  BEING  FALSE) 

(S  BEING  FALSE)) 

(THE  UNDERLYING  PREMISES  ARE 
(1  (OR  R  S)  IS  TRUE) 

(2  (NOT  R)  IS  TRUE) 

(3  (NOT  S)  IS  TRUE)) 

(WHICH  PREMISE  SH0UL0  BE  RETRACTED  >))  3 

(why  •*) 

(S  IS  TRUE  FROM 
(1  (OR  R  S)  IS  TRUE) 

(2  R  IS  false)) 
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deducing  that  (not  c)  must  be  false  when  the  truth  of  (not  c)  is  retracted. 

One  simple  solution  is  to  add  a  clause  which  contains  the  negations  of  all  the  premises  underlying 
the  contradiction.  In  the  ease  of  scenario  S  this  clause  is: 

(v  ((or  a  b) .  false)  ((->  a  c) .  false)  ((->  b  c) .  false)  ((not  c) .  false)) 

Any  such  generated  clause  is  guaranteed  to  be  a  logical  tautology  because  all  of  the  involved  premises  lead  to 
a  contradiction  given  the  clauses  already  in  the  system,  which  arc  themselves  all  logical  tautologies.  Once 
such  a  clause  is  added  it  can  be  used  to  deduce  the  negation  of  any  one  of  the  premises  whenever  all  the 
others  are  believed.  Thus  when  a  single  premise  is  retracted  its  negation  is  guaranteed  to  be  dcduciblc  by  the 
system. 

Actually  the  I  MS  uses  a  more  complex  algorithm  which  performs  local  clause  resolution.  This 


Scenario  5.  Another  example  of  backtracking 


(assert  ■(->  a  c ) ) 

(->  A  C) 

(assert  '(->  b  c)) 

(->  B  C) 

(assert  '(or  a  b) ) 

(OR  A  B) 

(mhy  ' C ) 

(I  DONT  KNOW  WHETHER  C  IS  TRUE  OR  FALSE) 

(assert  '(not  c ) ) 

((THERE  IS  A  CONTRADICTION  FROM 
(A  IS  FALSE) 

(B  IS  FALSE) 

((OR  A  B)  IS  TRUE)) 

(THE  UNDERLYING  PREMISES  ARE 
(1  (->  A  C)  IS  TRUE) 

(2  (->  B  C)  IS  TRUE) 

(3  (OR  A  B)  IS  TRUE) 

(4  (NOT  C)  IS  TRUE)) 

(WHICH  PREMISE  SHOULD  BE  RETRACTED  >))  4 

(why  'c) 

(C  IS  TRUE  FROM 
(1  (NOT  C)  IS  FALSE)) 

(why  1) 

((NOT  C)  IS  TALSE  FROM 
(1  (->  A  C)  IS  TRUE) 

(2  (•>  B  C)  IS  TRUE) 

(3  (OR  A  B)  IS  TRUE)) 


i 
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Scenario  6.  An  Kxamplc  of  Refutation 


(assert  '(->  a  b)) 

(->  A  B) 

(assert  •(->  b  c ) ) 

(->  B  C) 

(why  •(->  a  c)) 

(I  DOMT  KNOW  WHETHER  (->  A  C)  IS  TRUE  OR  FALSE) 

(try-to-show  '(->  a  c)) 

T 

(why  *(->  a  C)) 

((->  A  C)  IS  TRUE  FROM 
(1  (->  A  B)  IS  TRUE) 

(2  (->  B  C)  IS  TRUE)) 


produces  more  local  constraints  which  arc  deductively  more  powerful  and  give  shorter,  more  structured 
justifications  when  they  arc  used  in  deductions.  However  the  details  of  this  more  sophisticated  procedure  are 
irrelevant  to  the  current  discussion  and  the  interested  reader  is  referred  to  appendix  one  for  the  Lisp  code 
which  performs  backtracking  in  the  implemented  TMS. 

The  backtracking  mechanism  can  be  used  in  a  refutation  technique  which  increases  the  deductive 
power  of  the  system.  In  refutation  the  system  attempts  to  deduce  a  specific  truth  value  for  an  assertion  by  first 
adding  the  negation  of  that  value  as  a  premise.  If  no  contradiction  arises  then  the  attempted  deduction  fails 
and  the  added  truth  value  is  removed.  If  a  contradiction  docs  arise  then  the  added  value  must  underlie  it  and 
die  system  deduces  die  negation  of  this  value  in  the  standard  backtracking  manner.  Thus  the  desired  truth 
value  gets  deduced.  Scenario  6  gives  an  example  of  the  use  of  a  try-to-show  (unction  which  invokes  the 
refutation  mechanism. 
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3.  PREMISE  CONTROL 

The  I  MS  can  be  thought  of  as  an  instrument  which  allows  one  to  view  the  consequences  of  a 
premise  set.  Being  similar  to  other  instruments  of  examination,  the  I  MS  is  useful  not  only  in  examining 
given  premise  sets,  but  also  in  determining  those  premises  which  are  of  interest.  This  Chapter  investigates 
some  ways  in  which  the  TMS  can  be  used  to  feed  back  information  from  the  asscrtional  data  base  in 
manipulating  the  premise  set  under  examination. 

A  premise  controller  can  be  used  to  automate  some  manipulations  of  the  premise  set.  Ihis  premise 
controller  can  have  data  structures  which  arc  completely  independent  of  the  asscrtional  data  base.  For 
example  the  premise  controller  might  associate  likelihoods  with  each  potential  premise,  lhc  user  could  then 
manipulate  these  likelihoods  leaving  the  actual  premise  control  up  to  the  controller.  The  first  two  sections  of 
this  chapter  investigate  some  methods  for  doing  this  type  of  automatic  premise  control. 

The  premise  controller  can  also  make  use  of  the  asscrtional  data  base  when  choosing  premises.  For 
example  suppose  that  the  I  MS  has  deduced  that  the  assertion  (taller  Rill  John)  is  true,  which  is  interpreted  as 
saying  that  Bill  is  tiller  than  John.  In  this  case  it  might  be  useful  to  assume  that  Bill  is  heavier  than  John.  The 
last  section  of  this  chapter  describes  a  technique  for  having  this  kind  of  premise  control  done  automatically. 

3.1.  Assumptions 

A  simple  premise  controller  can  be  constructed  by  making  a  distinction  between  solid  facts  and 
assumptions.  In  this  system  the  user  would  specify  a  set  of  solid  facts  and  a  set  of  assumptions.  'Hie  premise 
controller  would  then  put  both  in  the  premise  set  If  contradictions  arise  then  the  premise  controller  will 
always  retract  an  assumption  before  retracting  a  solid  fact.  If  there  is  more  than  one  assumption  underlying  a 
contradiction  then  the  user  is  asked  to  choose  one  for  retraction.  Similarly  if  a  contradiction  arises  which  has 
no  underlying  assumptions  then  the  user  must  choose  some  "solid  fact”  for  retraction. 

An  example  of  the  use  of  assumptions  in  premise  control  is  given  in  Scenario  7.  In  this  scenario,  and 
all  those  that  follow,  the  user  is  interacting  with  a  premise  controller  which  in  turn  deals  directly  with  the 
TMS.  Ihus  the  assert  function  tells  the  premise  controller  that  the  given  assertion  is  a  solid  fact,  and  the 
assume  function  tells  it  that  the  given  assertion  is  an  assumption. 

In  scenario  7  the  premise  controller  is  given  two  assumptions.  First  r  is  assumed,  which  leads  to  a 
deduction  that  t  is  false.  Then  t  is  assumed  and  the  premise  controller  makes  t  a  premise.  This  causes  the 
clause  which  justified  t  being  false  to  become  a  contradiction.  When  this  contradiction  occurs  only  the 
assumptions  underlying  the  contradiction  arc  presented  to  the  user,  thus  the  two  implications,  (■>  r  s)  and  (*> 
s  (not  t)).  arc  not  considered  for  retraction.  When  the  assumption  r  is  retracted  its  negation  is  automatically 
deduced. 

Another  example  of  premise  control  via  assumptions  is  given  in  scenario  8.  In  this  scenario  three 
assumptions  arc  made,  logical  constraints  arc  placed  on  these  assumptions  such  that  any  one  of  them  can  be 
true,  but  any  two  of  them  lead  to  a  contradiction.  When  r  and  s  arc  both  assumed  a  contradiction  arises  and 
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Scenario  7.  An  K.xamplc  of  Premise  Control  with  Assumptions 


(assert  *(->  r  s)) 

(->  R  S) 

(assert  '(->  $  (not  t))) 

(->  S  (MOT  T)) 

(assume  *r) 

R 

(«hy  ’t) 

(T  IS  FALSE  FROM 
(1  (MOT  T)  IS  TRUE)) 

(assume  ’t) 

((CONTRADICTION  FROM 
(T  IS  TRUE) 

((NOT  T)  IS  TRUE)) 

(UNDERLYING  ASSUMPTIONS  ARE 
(1  T  IS  TRUE) 

(2  R  IS  TRUE)) 

(WHICH  ASSUMPTION  SHOULD  BE  RETRACTED))  2 
(why  r) 

(R  IS  FALSE  FROM 
(5  (->  R  S)  IS  TRUE) 

(2  S  IS  FALSE)) 


the  user  makes  a  choice  between  these  two  assumptions,  leading  to  a  retraction  of  r.  When  t  is  assumed  the 
user  must  then  choose  between  t  and  s,  leading  to  a  retraction  of  s.  At  this  point  the  user  has  not  expressed 
any  preference  between  r  and  t,  both  of  which  were  given  to  the  premise  controller  as  assumptions.  So  the 
premise  controller  reinstates  r  as  a  premise  and  forces  this  choice  to  be  made.  In  general  the  premise 
controller  never  makes  an  arbitrary  choice  between  assumptions. 

3.2.  Likelihood  Classes 

A  generalization  of  the  assumption  approach  to  premise  control  involves  placing  potential  premises 
in  likelihood  classes.  The  assumption  approach  can  be  viewed  as  a  special  ease  of  this  in  which  there  arc  two 
likelihood  classes,  one  for  known  facts  and  one  for  assumptions.  When  contradictions  arise  in  the  general 
likelihood  approach,  less  likely  assumptions  arc  always  preferred  for  retraction.  The  user  need  only  be 
consulted  when  there  arc  several  premises  which  tie  for  being  the  least  likely  premises  underlying  a 
contradiction.  Again  the  premise  controller  is  very  careful  not  to  make  arbitrary  choices  between  premises  in 
the  same  class. 

An  example  of  a  ease  in  which  it  might  be  desirable  to  have  more  than  two  premise  classes  involves  a 
numerical  approximately  equal  relation,  ~.  Such  a  relation  is  not  truly  transitive,  i.c.  ("•  a  b)  and  (~  b  c)  docs 
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Scenario  8.  A  More  Complex  K\ ample 


(assert  '(not  (and  r  s))) 

(NOT  (AMO  R  S)) 

(assart  ‘(not  (and  s  t ) ) ) 

(MOT  (AMO  S  T) ) 

(assart  '(not  (and  r  t))) 

(NOT  (AMO  R  T)) 

(as  sum  ’r) 

R 

(as junta  ‘s) 

((CONTRADICTION  FROM 
(ANO  R  S)  IS  FALSE) 

(S  IS  TRUE) 

«  (R  IS  TRUE)) 

(THE  UNDERLYING  ASSUMPTIONS  ARC 
(1  S  IS  TRUE) 

(2  R  IS  TRUE)) 

(WHICH  SHOULO  BE  RETRACTED))  2 

(assume  ’t) 

((CONTRADICTION  FROM 
((AND  S  T)  IS  FALSE) 

(S  IS  TRUE) 

(T  IS  TRUE)) 

(THE  UNDERLYING  ASSUMPTIONS  ARC 
(1  S  IS  TRUE) 

(2  T  IS  TRUE)) 

(WHICH  SHOULO  BE  RETRACTED))  1 

((CONTRADICTION  FROM 
((AND  R  T)  IS  FALSE) 

(R  IS  TRUE) 

(T  IS  TRUE)) 

(THE  UNDERLYING  ASSUMPTIONS  ARC 
(1  R  IS  TRUE) 

(2  T  IS  TRUE)) 

(WHICH  SHOULO  BE  RETRACTED))  1 


not  necessarily  imply  that  (~  a  c);  otherwise  one  amid  prove  that  things  of  arbitrarily  differing  size  weft 
roughly  equal.  However  one  might  want  to  consider  this  transitivity  to  be  very  likely.  One  might  also  have 
other  assumptions  in  the  systems,  say  about  transistor  states  which  arc  much  less  certain.  Ihus  one  would 
want  at  least  three  likelihood  classes  used  in  premise  control,  one  for  known  ficts,  one  for  facts  derived  from 
the  transitivity  of  die  roughly  equal  relation,  and  one  for  less  certain  assumptions.  The  code  for  a  premise 
controller  of  this  type  s  presented  in  appendix  two. 
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3.3.  Likelihood  Assertions 

In  addition  to  retracting  premises  which  lead  to  a  contradiction,  a  premise  controller  should  be  able 
to  use  deductions  made  by  the  I  MS  to  do  more  positive  types  of  premise  control.  For  example,  if  it  has  been 
deduced  that  one  person  is  taller  than  another,  one  might  want  to  assume  that  he  is  also  heavier.  Or  if  one  has 
deduced  that  some  animal  is  a  bird,  one  might  want  to  assume  that  it  can  fly.  This  type  of  premise  control  can 
be  done  with  likelihood  assertions. 

Assuming  that  the  a  general  likelihood  class  approach  is  taken  to  premise  control,  one  can  imagine 
likelihood  assertions  of  the  form:  (very-likely  p).  which  is  intended  to  mean  that  the  assertion  p  is  very  likely  to 
be  true.  There  could  be  a  whole  range  of  such  likelihood  "predicates"  such  as  somewhat-likely,  likely, 
very-likely,  etc.  Of  course  it  remains  to  be  shown  how  a  system  is  capable  of  using  (or  "understanding")  such 
assertions. 

One  way  of  using  such  assertions  is  to  have  the  premise  controller  continually  monitor  the  data  base 
and  use  them  in  placing  potential  premises  in  likelihood  classes.  However  if  the  system  has  assumed  that 
some  animal  can  fly  it  might  be  nice  to  know  why  this  assumption  was  made.  While  it  would  be  possible  to 
place  justification  machinery  in  the  premise  controller  there  is  a  much  simpler  solution.  For  each  assertion  of 
the  form  (likely  p)  the  system  automatically  creates  the  assertion  (->  (likely  p)  p).  Ibis  implication  is  then 
considered  to  be  a  "likely"  premise  by  the  premise  controller.  Similar  implications  would  be  created  for  other 
likelihood  predicates  and  given  corresponding  status  in  the  premise  controller.  In  (his  way  if  the  assertion 
(likely  p)  is  ever  deduced  to  be  true,  the  assertion  p  will  also  become  true.  Ihe  support  for  p  will  involve  the 
likelihood  assertion  and  it  will  therefore  be  clear  why  p  is  believed.  However  if  the  deduction  of  p  ever  leads 
to  a  contradiction  then  the  assumption  (->  (likely  p)  p)  can  be  retracted.  Scenario  9  gives  an  example  of  the 
use  of  a  likelihood  assertion. 


Scenario  9.  A  use  of  Likelihood  Assertions 


(•start  '(->  (bird  frad)  (llkaly  (fty»  trad)))) 

(->  (BIRO  FRIO)  (LIKELY  (fLYS  FRED))) 

(•start  '(bird  frad)) 

(BIRO  FREO) 

(«hy  '(Flys  frad)) 

((FLYS  FREO)  IS  TRUE  FROM 

(1  (->  (LIKELY  (FLYS  FREO))  (FLYS  FREO))  IS  TRUE) 
(2  (LIKELY  (FLYS  FREO))  IS  TRUE)) 

(alty  2) 

((LIKELY  (FLYS  FREO))  IS  TRUE  FROM 
(1  (•>  (BIRO  FREO)  (LIKELY  (FLYS  FRED)))  IS  TRUE) 
(2  (BIRD  FREO)  IS  TRUE)) 
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4.  INSTANTIATION  CONTROL 

It  is  well  known  that  automated  deduction  and  theorem  proving  systems  arc  subject  to  explosive 
computations.  However  the  I  MS  described  in  the  previous  sections  seems  free  of  this  problem.  While  it  is 
possible  to  make  the  premise  controller  do  a  great  deal  of  backtracking  (exponential  in  the  number  of 
backtrackable  assumptions),  in  practice  this  is  not  important  because  the  number  of  assumptions  is  usually 
small  and  they  do  not  interact  in  complex  manners.  The  difference  between  the  I  MS  and  more  general 
deductive  systems  is  that  the  I  MS  deals  with  propositional  logic  only.  All  of  the  difficult  problems  in 
automated  deduction  involve  instantiation  of  quantified  formulae  and  axiom  schemas. 

From  the  point  of  view  taken  here  instantiation  and  deduction  are  separate  processes.  Deduction  is 
the  process  of  assigning  truth  values  to  assertions  based  on  other  truth  values  already  in  the  system.  This  can 
be  done  entirely  by  the  I  MS.  Instantiation  can  be  though  of  as  generating  propositional  formulae  upon 
which  the  I  MS  can  operate,  litis  outlook  on  deduction  leads  to  novel  control  strategies. 

4.1.  For- A II  Assertions 

Quantified  knowledge  can  be  represented  in  for-all  assertions.  Scenario  10  gives  an  example  of  the 
use  of  such  assertions.  In  (his  scenario  the  assertion  (for-all  (dog  !x)  (mammal  !x»  represents  the  statement 
that  all  dogs  arc  mammals.  In  general  a  for-all  assertion  has  two  parts.  The  first  is  an  "antecedent  assertion" 
such  as  (dog  !x)  in  the  example,  and  is  similar  to  a  trigger  pattern  in  a  Pl.ANNKR  demon.  Symbols  which 
begin  with  the  character  ”!"  arc  treated  as  variables  which  can  match  any  s-expression.  The  second  part  of  a 
for-all  assertion  is  a  consequent  assertion,  instances  of  which  follow  from  the  for-all  assertion  and 
corresponding  instances  of  the  antecedent  assertion. 

For  deductions  to  be  made  from  the  assertion  (for-all  (dog  !x)  (mammal  !x»  constraints  must  be 
placed  in  the  I  MS  which  involve  this  assertion.  I  MS  constraints  for  assertions  involving  the  basic  logical 
connectives  arc  derived  from  axioms  for  those  connectives.  Similarly  constraints  involving  for-all  assertions 
arc  derived  from  implicit  axioms  for  for-all.  The  following  constraint  is  an  instance  of  these  axioms.  It  says 
that  the  above  for-all  assertion  along  with  the  assertion  (dog  Fred)  implies  the  assertion  (mammal  Fred). 

(v  ((for-all  (dog  lx)  (mammal  lx))  .  falsa) 

((dog  Frad)  .  falsa) 

((mammal  Frad)  .  trua)) 

• 

It  is  dear  that  it  would  be  impossible  to  generate  all  instances  of  the  axioms  for  for-all  assertions 
whenever  such  an  assertion  is  created  in  the  data  base.  Ihcrcforc  some  more  sophisticated  control  technique 
is  required  for  this  instantiation  process.  When  a  for-all  assertion  is  created  a  demon  is  constructed  which  is 
invoked  every  time  an  assertion  that  matches  the  antecedent  pattern  is  created  in  the  data  base.  Flach  time  this 
demon  is  invoked  it  uses  the  variable  binding  generated  by  the  triggering  assertion  to  create  a  corresponding 
instance  of  the  consequent  assertion.  Then  it  adds  a  constraint,  similar  to  the  one  above,  which  states  that  die 
for-all  assertion  along  with  this  instance  of  the  antecedent  assertion  implies  the  instance  of  the  consequent 
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Scenario  10.  A  use  of  for-all 


(assert  '(for-all  (dog  lx)  (mammal  lx))) 
(FOR-AU  (DOG  IX)  (MAMMAL  IX)) 

(assert  '(dog  fred)) 

(DOG  FREO) 

(why  '(mammal  fred)) 

((MAMMAL  FREO)  IS  TRUE  FROM 
(1  (FOR-ALL  (OOG  IX)  (MAMMAL  IX))  IS  TRUE) 
(2  (DOG  FRED)  IS  TRUE)) 


assertion.  It  is  important  to  keep  in  mind  that  the  triggering  condition  is  the  creation  of  an  assertion  not  the 
assignment  of  a  true  truth  value  to  that  assertion.  Thus  the  above  constraint  could  have  been  generated  even  if 
the  assertion  (dog  fred)  was  not  known  to  be  true.  In  this  ease  the  constraint  could  be  used  to  deduce  that  this 
assertion  is  in  fact  false. 

4.2.  Taxonomic  Hierarchies:  An  Example 

A  system  for  reasoning  about  taxonomic  hierarchies  will  be  developed  in  this  section.  Hach 
taxonomic  class  is  represented  by  a  predicate.  The  taxonomic  hierarchy  can.be  represented  by  assertions  of 
the  form: 


(for-all  (cat  lx)  (mammal  lx)) 

(for-all  (dog  lx)  (mammal  lx)) 

(for-all  (dog  lx)  (not  (cat  lx))) 

(for-all  (cat  lx)  (not  (dog  lx))) 

Figure  2  shows  a  taxonomic  hierarchy.  A  set  of  assertions  similar  to  the  above  assertions  concerning 
the  predicate  mammal  arc  asserted  for  each  non-terminal  predicate  in  the  hierarchical  tree.  Scenario  11  gives 
some  sample  deductions  the  system  is  capable  of  making  from  these  assertions.  When  the  assertion  (mouse 
fred)  is  created  the  assertion  (rodent  fred)  is  also  created  and  a  constraint  is  installed  which  says  that  die 
assertion  that  all  mice  arc  rodents  along  with  the  assertion  that  Fred  is  a  mouse  imply  the  assertion  that  Fred 
is  a  rodent.  The  creation  of  the  assertion  (rodent  fred)  in  turn  leads  to  the  creation  of  other  constraints  and 
assertions  until  the  top  of  the  hierarchy  is  reached.  Now  when  (rodent  fred)  becomes  true,  the  TMS 
automatically  deduces  that  fred  is  a  member  of  every  class  superior  to  rodent  in  the  hierarchy. 

Now  consider  what  the  system  docs  in  response  to  the  form  (why  '(ladybug  fred)).  Since  the 
assertion  (ladybug  fred)  did  not  exist  previously  in  the  system  the  why  function  first  creates  this  assertion.  This 
creation  results  in  the  creation  of  further  assertions  and  logical  constraints.  Ihcsc  newly  created  constraint! 
interact  with  the  previous  constraints  at  die  level  of  vertebrate  and  arthropod.  Since  it  was  asserted  in 
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Fig.  L  A  Simple  Taxonomic  Hierarchy 


animal 


A  A 


mouse  rabbit  June  bug  ladybug 


Scenario  II.  Some  Deductions  Involving  the  Taxonomic  Hierarchy 


(assert  '(mouse  Trad)) 

(MOUSE  FRED) 

(why  '(vertebrate  Fred)) 

((VERTEBRATE  FRED)  IS  TRUE  FROM 
(1  (FOR-ALL  (MAMMAL  IX)  (VERTEBRATE  IX))  IS  TRUE) 
(2  (MAMMAL  FRED)  IS  TRUE)) 

(•by  '(ladybug  Fred)) 

((LAOVBUG  FREO)  IS  FALSE  FROM 
(1  (FOR-ALL  (LAOVBUG  IX)  (BEETLE  IX))  IS  TRUE) 

(2  (BEETLE  FREO)  IS  FALSE)) 


constructing  the  hierarchy  that  no  vertebrates  arc  arthropods,  the  system  had  already  deduced  that  the 
assertion  (arthropod  fred)  was  false.  This  leads  to  the  deduction  that  Fred  is  not  an  insect,  and  therefore  not  a 
beetle,  and  therefore  not  a  ladybug. 

The  time  it  takes  it  takes  to  do  the  types  of  instantiations  and  deductions  exemplified  in  scenario  11 
is  proportional  to  the  depth  of  the  hierarchy  which  is  usually  proportional  to  the  log  of  the  number  of  classes 
involved.  Ihc  interesting  tiling  about  the  above  deductions  however  is  not  the  efficient  computation  time 
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involved  but  instead  the  simplicity  of  the  control  structure  used  in  achieving  it.  Normally  to  achieve 
comparable  efficiency  one  would  have  to  use  both  forward  chaining  and  backward  chaining  control  structures 
(Moore  75],  Here  a  single  method  for  controlling  instantiation  (as  opposed  to  deduction)  fully  achieves  the 
desired  efficiency. 

4.3.  Areas  for  Further  Research 

Ihc  instantiation  control  techniques  which  have  been  discussed  so  far  arc  only  a  beginning.  Not  all 
domains  in  deduction  lend  themselves  to  so  simple  a  solution  as  do  taxonomic  hierarchies.  The  simple 
statement  that  the  mother  of  any  person  is  a  person  leads  to  infinite  instantiation  if  a  standard  for-all  assertion 
is  used,  litis  section  gives  some  directions  for  research  into  other  instantiation  control  techniques.  Ihc  major 
point  here  does  not  concern  specific  mechanisms  for  controlling  instantiation,  but  rather  that  control  of 
deduction  in  general  should  be  thought  of  as  control  of  instantiation. 

4.3.1  DEMONIC  INVOCATION 

In  controlling  the  instantiation  of  quantified  knowledge  one  would  like  a  convenient  way  of 
specifying  general  conditions  under  which  instantiation  is  to  take  place.  Ihc  axioms  for  the  basic 
propositional  logical  operators  get  instantiated  whenever  an  assertion  using  one  of  these  operators  is  created 
in  the  data  base.  This  type  of  demonic  invocation  will  be  called  "reference  invocation".  Ihc  following  is  a 
demon  specification  utilizing  reference  invocation  which  might  be  used  to  control  the  knowledge  that  the 
mother  of  any  person  is  a  person: 

(notice  ((assertion-reference  (person  lx)) 

(term-reference  (mother  lx))) 

( Instal 1 -constraint  '(->  (and  (person  lx) 

(for-alt  y 

(->  (person  y) 

(person  (mother  y))))) 

(person  (mother  lx))))) 

Demon  specifications  of  the  above  form  have  two  parts.  First  is  a  set  of  conditions  which  must  be 
met  for  the  demon  to  fire.  Ihc  second  is  a  body  of  Lisp  code  which  defines  the  action  taken  by  the  demon 
when  it  fires.  The  trigger  conditions  of  the  above  demon  arc  both  reference  conditions  which  arc  met 
whenever  a  term  or  assertion  matching  the  given  pattern  is  referenced.  When  a  demon  is  triggered  the 
variables  in  the  trigger  patterns  arc  bound  to  s-expressions  representing  terms  and  assertions.  Ihcsc  bindings 
arc  then  used  to  replace  all  occurrences  of  the  variables  in  the  body  with  the  corresponding  s-expressions 
before  the  body  is  evaluated.  In  the  above  example  install-constraint  is  used  instead  of  assert  because  the 
implication  being  asserted  is  really  a  logical  tautology  and  therefore  only  a  I  MS  clause  equivalent  to  the 
implication  need  be  created  (no  node  is  generated  to  represent  the  implication  itself). 

Other  types  of  trigger  conditions  arc  conceivable.  Ihc  simplest  would  trigger  whenever  assertions  of 
a  certain  form  became  true  (or  false).  Assertions  and  terms  might  also  be  assigned  "intcrcstingncss".  Demons 
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could  then  trigger  when  assertions  or  terms  of  certain  forms  arc  "interesting”.  Such  control  states  assigned  to 
assertions  and  terms  would  be  closely  related  to  "control  assertions"  which  have  been  used  in  some  recent 
work  with  pattern  directed  invocation  systems  (dc  Klccr  cl  al.  77)  [Shrobc  79J.  However  the  use  of  such 
techniques  for  instantiation  control  (as  opposed  to  deduction  control)  is  still  largely  unexplored. 

4.3.2  SPKC1AL  PURPOSE  SUBSYSTEMS 

An  important  aspect  of  any  automated  deduction  system  is  the  ease  with  which  special  purpose 
subsystems  can  be  incorporated.  For  example  one  almost  certainly  wants  some  special  purpose  algorithms  for 
dealing  with  equalities  [Nelson  &  Oppen  79]  [McAllcster  80],  In  tire  present  context  such  algorithms  can  be 
viewed  as  controlling  the  instantiation  of  the  substitution  axioms  for  equality,  generating  new  terms  and 
equating  them  with  other  terms  in  the  system.  A  full  discussion  of  the  ways  equality  can  be  handled  is  beyond 
the  scope  of  this  work,  but  it  is  important  to  note  that  special  purpose  priced u res  seem  a  better  option  than 
any  attempt  to  handle  it  entirely  through  demonic  mechanisms. 

Another  example  of  an  area  in  which  special  purpose  subsystems  would  be  desirable  is  algebraic 
simplification.  There  are  good  algorithms  for  doing  symbolic  simplification  of  algebraic  expressions  and  any 
reasoning  system  which  must  manipulate  such  expressions  should  be  able  to  use  these  algorithms  [McAllcster 
80],  The  feasibility  of  incorporating  arbitrary  special  purpose  deduction  algorithms  and  decision  procedures  is 
only  beginning  to  be  explored. 
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5.  RELATION  TO  OTHER  WORK 

The  earliest  predecessor  to  the  system  described  here  is  probably  the  Davis-Putnam  algorithm  for 
determining  the  satisfiability  of  sentences  in  first  order  predicate  calculus  [Davis  &  Putnam  60].  lire  feature  of 
their  algorithm  which  resembles  the  TMS  is  their  technique  for  determining  satisfiability  of  purely 
propositional  sentences.  ITicir  method  translated  the  propositional  sentence  to  a  set  of  disjunctive  clauses  and 
then  performed  "propositional  constraint  propagation"  on  those  clauses  much  as  docs  die  I  MS  (but  they  did 
not  call  it  that).  Propositional  constraint  propagation  can  also  be  seen  to  be  very  similar  to  unit  clause 
resolution  (resolving  first  with  clauses  which  contain  only  a  single  term).  However  it  is  not  really  appropriate 
to  compare  the  I  MS  to  any  full  fledged  resolution  system  since  the  I  MS  docs  not  deal  with  variables  (Le. 
quantified  formula). 

These  early  systems  however  did  not  perform  the  basic  I  MS  functions  of  justification  maintenance, 
incremental  retraction,  and  dependency  directed  backtracking.  The  earliest  attempt  to  handle  incremental 
retraction  probably  dates  back  to  the  "add"  and  "delete"  lists  in  the  STRIPS  language  [I-'ikcs  71J.  and 
Pl.ANNKR  demons  which  triggered  on  the  removal  of  assertions  [Hew  itt  72]  (Sussman  71]  (McDermott  74). 
Later  a  dependency  based  mechanism  was  developed  by  Richard  Kikes  for  reasoning  about  state  transitions 
[Kikes  75],  A  more  sophisticated  dependency  directed  retraction  mechanism  was  later  developed  by  Stallman 
and  Sussman  for  use  in  an  electrical  circuit  analysis  system  [Stallman  &  Sussman  77],  Ihcir  system  could 
make  assumptions  about  transistor  states,  and  when  a  contradiction  was  derived,  the  system  uses  dependency 
directed  backtracking  to  track  down  the  particular  underlying  assumptions. 

The  first  domain  independent  system  which  performed  all  of  the  basic  truth  maintenance  functions 
was  developed  by  Jon  Doyle  [Doyle  78].  Doyle’s  system  used  "non-monotonic"  dependencies  which  justify  a 
node  being  "in"  by  the  fact  that  some  other  node  is  "out".  Such  dependencies  arc  typically  used  to  make 
assumptions.  Kor  example  one  might  assume  A  by  justifying  A  with  the  fact  that  (not  A)  is  out.  Thus  if  (not  A) 
ever  becomes  in,  the  justification  for  A  will  no  longer  be  valid  and  A  will  become  out.  This  leads  to  problems 
however  if  the  system  is  able  to  prove  (not  A)  from  the  assumption  of  A.  First  (not  A)  comes  in  forcing  A  out. 
But  because  (not  A)  depends  on  A  this  in  turn  causes  (not  A)  to  become  out.  which,  via  the  non  monotonic 
dependency,  leads  to  A  becoming  in,  which  leads  to  (not  A)  becoming  in,  ad  infinitum.  While  there  may  be 
ways  to  fix  this  problem,  it  seems  hard  to  motivate  the  introduction  of  non-monotonic  mechanisms  which  lead 
to  unnecessary  complications. 

Another  problem  with  non-monotonic  systems  is  their  obscure  semantics.  Attempts  to  formalize 
"non-monotonic  logics"  arc  plagued  by  "unsatisfiablc"  situations  similar  to  the  infinite  computation 
described  above  (McDermott  78).  While  it  may  be  possible  to  debug  these  problems,  the  fundamental 
motivation  behind  non-monotonic  justifications  is  suspect.  Certainly  one  cannot  argue  that  an  assumption  is 
made  because  one  cannot  prove  its  negation.  At  any  time  there  is  an  infinite  number  of  assertions  which  the 
system  can  not  prove  to  be  false,  but  one  would  certainly  not  want  to  assume  all  these  things.  I’hcrefore  a 
non-monotonic  justification  docs  not  capture  the  true  reason  for  making  an  assumption.  It  might  capture  what 
the  system  should  do  if  it  could  prove  the  negation  of  an  assumption,  but  this  is  a  backtracking  issue  and 


*«**>  VatM4 


August  1980 


5.  RELATION  TO  OTHER  WORK  •  20  - 


should  not  be  represented  as  a  justification. 

In  the  truth  maintenance  system  described  in  this  paper  as  much  as  possible  is  done  in  a  traditional 
framework.  The  problem  with  non  monotonic  logics  is  that  they  bring  in  non-traditional  formalisms  too 
early,  muddying  deduction,  justifications,  and  backtracking.  The  aspect  of  truth  maintenance  which  cannot  be 
formalized  in  a  traditional  framework  is  premise  control,  which  has  only  just  begun  to  be  explored,  foofoo 
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6.  APPENDIX  I:  THE  TMS  CODE 


6.1.  The  User  Interface 


These  functions  interact  with  the  the  premise  controller,  lhe  premise  controller  works  on  a  priority 
class  scheme  which  can  be  initialized  to  have  any  number  of  priority  classes,  which  are  assigned  consecutive 
integers  from  the  least  to  the  most  certain.  The  user  level  functions  given  here  work  with  three  priority  classes, 
numbered  1  through  3.  The  functions  assert  and  assume  put  assertions  in  the  most  certain  and  least  certain 
classes  respectively,  l  he  middle  class  is  accessed  via  very-likely  assertions,  which  arc  documented  below. 


(prmcon-lnit  1  3) 

(defun  assert  (assertion) 

(set-default  ( referenced-node  assertion)  'true  3) 
assertion) 

(defun  assume  (assertion) 

(set-default  (referenced-node  assertion)  'true  1) 
assertion) 

(defun  retract  (assertion) 

(remove-default  (referenced-node  assertion))) 

ITic  assertions  arc  placed  in  a  hash  table  which  is  used  to  insure  that  no  two  I  MS  nodes  have  the 
same  assertion. 


(declare  (special  •assertion-table*)) 

(setq  •assertion-table*  (make-array  nil  'art-q  4000)) 

(defun  inde*  (form) 

(remainder  (hash  form)  4000)) 

(defun  referenced-node  (assertion) 

(let  ((ass  (virt-assoc  assertion 

(ar-1  ‘assertion-table*  (index  assertion))))) 

(if  (edr  ass) 

(edr  ass) 

(let  ((node  (make-tms-node))) 

(setf  (edr  ass)  node) 

(setf  (assertion  node)  assertion) 

(instantiate  node  assertion) 
node)))) 

(defmacro  in-funs  (symbol) 

'(get  .symbol  'In-funs)) 

(defun  Instantiate  (node  assertion) 

(if  (and  (listp  assertion)  (symbolp  (car  assertion))) 

(mape  'funcall  (In-funs  (car  assertion)) 

(circular-list  node) 

(circular-list  assertion)))) 
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I'hcsc  functions  instantiate  the  basic  axioms  of  propositional  logic  in  the  TMS. 


(defun  ->in$tance  (node  assertion) 

(tet  ( ( nl  ( ref erenced-node  (cadr  assertion))) 

(n2  (referenced-node  (caddr  assertion)))) 

(add*clause  (list  (cons  node  ‘false) 

(cons  nl  ‘false) 

(cons  n2  ‘true))) 

(add-clause  (list  (cons  node  ‘true)  (cons  nl  'true))) 

(add-clause  (list  (cons  node  ‘true)  (cons  n2  ’false))))) 

(addf  '->1nstance  (in-funs  ’->)) 

(defun  or-instance  (node  assertion) 

(let  ((nl  (referenced-node  (cadr  assertion))) 

(n2  (referenced-node  (caddr  assertion)))) 

(add-clause  (list  (cons  node  'false) 

(cons  nl  'true) 

(cons  n2  ’true))) 

(add-clause  (list  (cons  node  ‘true)  (cons  nl  'false))) 

(add-clause  (list  (cons  node  ‘true)  (cons  n2  ’false))))) 

(addf  'or-1nstance  (in-funs  ’or)) 

(defun  and-lnstance  (node  assertion) 

(let  ((nl  (referenced-node  (cadr  assertion))) 

(n2  (referenced-node  (caddr  assertion)))) 

(add-clause  (list  (cons  node  ’true) 

(cons  nl  ’false) 

(cons  n2  ’false))) 

(add-clause  (list  (cons  node  ‘false)  (cons  nl  'true))) 

(add-clause  (list  (cons  node  ‘false)  (cons  n2  ’true))).)) 

(addf  'and-lnstance  (in-funs  ’and)) 

(defun  not-instance  (node  assertion) 

(let  ((nl  (referenced-node  (cadr  assertion)))) 

(add-clause  (list  (cons  node  ’true)  (cons  nl  ’true))) 
(add-clause  (list  (cons  node  ’false)  (cons  nl  ’false))))) 

(addf  'not-instance  (In-funs  ’not)) 

'I’hcsc  functions  interface  likelihood  assertions  with  the  premise  controller. 


(defun  1 Ikely-instance  (node  assertion) 

(assume  '(->  .assertion  ,(cadr  assertion)))) 

(addf  'likely-instance  (in-funs  ’likely)) 

(defun  very-1 ikely-instance  (node  assertion) 

(let  ((nl  (referenced-node  '(->  .assertion  ,(cadr  assertion))))) 
(set-default  nl  ’true  2))) 


(addf  'very-1 Ikely-instance  (In-funs  ’very-likely)) 
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(defun  try-to-show  (assertion) 

(let  ((node  (referenced-node  assertion))) 

(refute  (cons  node  'false)) 

(eq  (truth  node)  ’true))) 

(defun  why  (Item) 

(if  (and  (numberp  Item)  (■  item  0)) 

(pop-query) 

(let  ((node  (if  (numberp  item) 

(answer  item) 

(referenced-node  item)))) 

(cond  ((unknown?  node) 

'(I  dont  know  whether  or  not  .(assertion  node)  is  true)) 

((null  (support  node)) 

'(.(assertion  node)  is  .(truth  node)  as 

,8(cdr  (assoc  (certainty  node)  '((1  a  likely) 

(2  a  very-likely) 

(3  an  asserted)))) 

premise)) 

(t  (push-query  (cons  '(.(assertion  node)  is  .(truth  node)  from) 

(fmapcar  '(lambda  (term) 

(if  (not  (eq  (car  term)  node)) 

(cons  '(.(assertion  (car  term)) 
is 

.(truth  (car  term))) 
(car  term)))) 

(clause-list  (support  node)))))))))) 
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6.2.  The  TMS 


(declare  (special  *contra-l  ist*  ‘removed-list*  ‘notlcers* 
•premise- selector*  •premise-checker*)) 

(defun  tms-init  (prem-selector  prem-ehecker) 

(setq  ‘premise-selector*  prem-selector) 

(setq  ‘premise-checker*  prem-checker) 

(setq  ‘contra-list*  nil) 

’ (tms-ready)) 

(defstruct  (tms-node) 
assertion 
(truth  'unknown) 
support 
true-noticers 
false-not icers 
unknown-noticers 
neg-clauses 
pos-clauses 
external -proper  ties) 

(defmacro  opposite  (value) 

'(if  (eq  .value  'true)  'false  'true)) 

(defmacro  clauses  (node  value) 

'(if  (eq  .value  ’true) 

(pos-clauses  .node) 

(neg-clauses  .node))) 

(defmacro  op-clauses  (node  value) 

'(if  (eq  .value  ’true) 

(neg-clauses  .node) 

(pos-clauses  .node))) 

(defmacro  noticers  (node  value) 

'(cond  ((eq  .value  ’true) 

(true-noticers  .node}) 

((eq  .value  ’false) 

(false-noticers  .node)) 

(t  (unknown-noticers  .node)))) 

(defmacro  unknown?  (node) 

'(eq  (truth  .node)  ’unknown)) 

(defmac  premise?  (node) 

(and  (not  (unknown?  node))  (null  (support  node)))) 

(defmac  true-term?  (term) 

(eq  (truth  (car  term))  (cdr  term))) 

(defmac  false-term?  (term) 

(eq  (truth  (car  term))  (opposite  (cdr  term)))) 

(defmacro  unknown- term?  (term) 

■(unknown?  (car  .term))) 

(defmacro  op-term  (term) 

’(cons  (car  .term)  (opposite  (cdr  .term)))) 
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(defmacro  make-clause  () 

’(cons  nil  nil)) 

(defmacro  clause-list  (clause) 

'(car  .clause)) 

(defmacro  psat  (clause) 

'(cdr  .clause)) 

(defun  add-clause  (clist) 

(let  ((clause  (add-2  clist)) 

(•noticers*  nil)) 

(deduce-check  clause) 

(run-noticers))) 

(defun  add-2  (c-list) 

(let  ((clause  (make-clause))) 

(setf  (clause-list  clause)  (merge  c-llst  nil)) 

(mapc  '(lambda  (term) 

(addf  clause  (clauses  (car  term)  (cdr  term)))) 
(clause-list  clause)) 

(setf  (psat  clause)  (comp-psat  (clause-list  clause))) 
clause) ) 

(deftail  comp-psat  (clist) 

(if  (null  clist) 

0 

(If  (not  (false-term?  (car  clist))) 

(1+  (comp-psat  (cdr  clist))) 

(comp-psat  (cdr  clist))))) 
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(defun  make-premise  (nod*  value) 

(lat  ((‘notlcer**  nil)) 

(cond  ((unknown?  nod*) 

(set-truth  nod*  valu*)) 

((•q  value  (truth  nod*)) 

(setf  (support  nod*)  nil)) 

(t  (let  ((‘removed-list*  nil)) 

(remove-truth  nod*) 

(set-truth  nod*  valu*) 

(removed-check)))) 

(run-notlcers))) 

(defun  set-truth  (nod*  valu*) 

(s*t-2  nod*  valu*) 

(mape  '(lambda  (notlcer) 

(addf  notlcer  ‘not.icers*)) 

(noticers  node  value)) 

(mape  ' deduce-check  (op-clauses  node  valu*))) 

(d*fun  set-2  (nod*  valu*) 

(mape  '(lambda  (clausa) 

(setf  (psat  clause)  (1-  (psat  clause)))) 
(op-clauses  nod*  valu*)) 

(setf  (truth  node)  value)) 

(defun  deduce-check  (clause) 

(cond  ((*  (psat  clause)  1) 

(let  ((term  (unknown-term  (clause-list  clause)))) 
(If  term 

(deduce  (car  term)  (edr  term)  clause)))) 
((•  (psat  clause)  0) 

(addf  clause  ‘contra-1 1st*)))) 

(deftall  unknown-term  (cl  1st) 

(cond  ((null  cllst)  nil) 

( (unknown-term?  (car  cllst)) 

(car  cllst)) 

(t  (unknown-term  (edr  cllst))))) 

(defun  deduce  (node  valu*  sup-claus*) 

(setf  (support  node)  sup-clause) 

(set-truth  node  valu*)) 
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(defun  retract-premise  (node) 

( if  (premise?  node) 

(let  ((’noticers*  nil) 

(•removed-list*  nil)) 

( remove-truth  node) 

(removed-check) 

(run-noticers)))) 

(defun  remove-truth  (node) 

(let  ((value  (truth  node))) 

(remove-?  node  value) 

(addf  node  *removed-l 1st*) 

(mapc  '  retrac t-check  (op-clauses  node  value)))) 

(defun  remove-?  (node  value) 

(if  (unknown?  node)  (break  ramoving-truth-of-unknown-node)) 

(mapc  '(lambda  (clausa) 

(setf  (psat  clause)  (1*  (psat  clause)))) 

(op-clauses  node  value)) 

(setf  (truth  node)  'unknown) 

(setf  (support  node)  nil)) 

(defun  retract-check  (clause) 

(if  (>  (psat  clause)  1) 

(let  ((node?  (satisfier  (clause-list  clause)))) 

(if  (and  node2  (eq  clause  (support  node?))) 

(remove-truth  node2))))) 

(deftail  satisfier  (clist) 

(cond  ((null  clist)  nil) 

((true-term?  (car  clist)) 

(caar  clist)) 

(t  (satisfier  (cdr  clist))))) 

All  nodes  whose  support  status  has  changed  (the  node’s  previous  support  was  invalidated)  arc  passed 
to  the  premise  controller  which  determines  if  die  premises  should  be  changed  based  on  the  current  support 
structure. 


(defun  removed-check  () 

(mapc  'node-deduce-check  *removed-11st*) 

(funcall  ‘premise-checker*  ‘removed-list*) 

(mapc  '(lambda  (node) 

(cond  ((unknown?  node) 

(mapc  '(lambda  (noticer)  (addf  noticer  ‘noticers*)) 
(unknown-notlcers  node))))) 

•removed-list*)) 

(defun  node-deduce-check  (node) 

(cond  ((unknown?  node) 

(node-check-2  node  'true  (pot-clauses  node)) 

(node-check-2  node  'false  (neg-clauses  node))))) 

(deftail  node-check-2  (node  value  clauses) 

(if  clauses 

(let  ((clause  (car  clauses))) 

(if  (■  1  (psat  clause)) 

(deduce  node  value  clause) 

(node-check-?  node  value  (cdr  clauses)))))) 
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(deftail  run-noticers  () 

(cond  (*contra-11st* 

(let  ((contra  (car  *contra-list*))) 

(setq  •contra-list*  (car  •contra-list*)) 

(if  (•  0  (psat  contra))  (backtrack  contra)) 

(run-noticers))) 

( ‘noticars* 

(let  ((next  (car  *noticera*))) 

(setq  ‘noticers*  (cdr  •notlcera*)) 

(aval  next) 

(run-noticers))))) 

(defun  backtrack  (contra) 

(let  ((prams  (premises  (clause-list  contra)))) 

(let  ((prem  (cond  ((null  prems)  (break  contradiction)) 

((null  (cdr  prems))  (car  prems)) 

(t  (funcall  •premise-selector*  prams))))) 

(let  ((path  (support-path  prem  (clause-list  contra))) 

(•removed-list*  nil)) 

(invert  path  contra) 

(deif  prem  ‘removed- 1 i st* )  ;  the  premise  controller  has  already  selected  this  node 
( removed- check ) ) ) ) ) 

(defmacro  premises  (clist) 

'(merge  (premises2  .clist)  nil)) 

(defun  premises2  (clist) 

(if  clist 

(if  (true-term?  (car  clist)) 

(premises  (cdr  clist)) 

(If  (premise?  (caar  clist)) 

(cons  (caar  clist)  (premises  (cdr  clist))) 

(nconc  (premises  (clause-list  (support  (caar  clist)))) 

(premises  (cdr  clist))))))) 


(defun  refute  (term) 

(let  (((node  .  value)  term)) 

(if  (unknown?  node) 

(let  ((‘removed-list*  nil) 

(•noticers*  nil) 

(•contra-list*  nil)) 

(set-truth  node  value) 

(let  ((path  (support-path  node  (clause-list  (car  *contra-11st*))))) 
(if  path 

(Invert  path  (car  ‘contra-1 1st*)) 

(remove-truth  node)) 

(removed-check) 

(run-noticers)) 

(if  (unknown?  node)  nil  t ) ) 

(print  '(warning  —  refutation  attempted  on  known  truth  value))))) 

The  following  is  a  useful  utility  in  choosing  premises  for  retraction 


(defun  user-choice  (assums) 

(push-query  '((there  is  a  conflict  between) 
,9(mapcar  '(lambda  (node) 

(cons  '(.(assertion  node) 
assumed  to  be 
.(truth  node)) 
node)) 

assums))) 

(print  '(which  assumption  should  be  retractedT)) 
(answer  (read))) 
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A  support  path  is  a  list  of  nodes  such  that  for  any  two  sequential  nodes  the  latter  node  is  in  the 
support  clause  for  the  former.  The  function  support-path  is  used  to  find  a  support  path  from  a  contradiction  to 
a  premise,  (support-path  node  clist)  returns  a  support  path  such  that  the  first  node  in  the  path  is  in  clist  and 
the  path  ends  with  node. 


(deftail  support-path  (nods  c-ttst) 

(cond  ((null  c-list)  nil) 

((true-term?  (car  clist)) 

(support-path  node  (edr  c-11st))) 

(t  (let  ((node2  (caar  c-11st))) 

(cond  ((eq  node  node2) 

(list  node)) 

( (premise?  node2) 

(support-path  node  (edr  c-11st))) 

(t  (let  ((path  (support-path  node  (clause-list  (support  node2))))) 
(if  path 

(cons  node2  path) 

(support-path  node  (edr  c-Ust) )))))))) ) 

(deftail  Invert  (path  contra) 

( If  path 

(let  ((node  (car  path))) 

(let  ((path2  (circular-path  node  contra))) 

(if  path2 

(let  ((node2  (car  path2))) 

(let  ((contra2  (add-2  (resolution  (path-resolution  path2) 

(clause-list  contra) 
node2)))) 

(Invert  path  contra2))) 

(let  ( (nest-contra  (support  node)) 

(value  (truth  node))) 

(remove-truth  node) 

(deduce  node  (opposite  value)  contra) 

(invert  (edr  path)  nest-contra))))))) 

(defun  circular-path  (node  contra) 

(support-path  node  (remove-node  node  (clause-list  contra)))) 

(defun  path-resolution  (path) 

(path-resolut1on2  (edr  path)  (clause-list  (support  (car  path))))) 

(deftail  path-resolut1on2  (rest-path  clist) 

(if  (edr  rest-path) 

(path-resolut1on2  (edr  rest-path) 

(resolution  clist 

(clause-list  (support  (car  rest-path))) 

(car  rest-path))) 

clist)) 

(defun  resolution  (cllstl  cl1st2  node) 

(append  (remove-node  node  cllstl) 

(remove-node  node  c11st2))) 

(deftail  remove-node  (node  clist) 

(If  (eq  (caar  clist)  node) 

(edr  clist) 

(cons  (car  clist)  (remove-node  node  (edr  clist))))) 
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6.3.  The  Premise  Controller 


The  premise  controller  is  best  understood  in  terms  of  the  invariants  it  enforces.  First  a  node  with  a 
default  truth  value  (one  that  is  in  some  premise  priority  class)  can  have  its  default  \aluc  as  a  deduced  value 
(instead  of  as  a  premise)  only  if  all  the  premises  underlying  that  deduction  arc  in  a  stronger  class.  Such  a  node 
can  take  on  the  opposite  of  its  default  value  only  when  the  premises  underlying  that  value  arc  in  stronger 
priority  classes  or  when  the  node  has  been  chosen  explicitly  by  the  user  for  retraction  when  it  conflicts  with 
other  premises  in  its  own  class. 


(declare  (special  ‘mln-cert*  ‘max-cart*)) 

(defun  prmcon-inlt  (mine  maxc) 

(tms-lnit  'prmcon-sel actor  'prmcon-checker) 

(setq  *min-cert*  mine) 

(setq  ‘max-cert*  maxc)) 

(d efmacro  default  (nods) 

'(edr  (vlrt-assq  'default  (external -properties  .node)))) 

(defmacro  default-certainty  (node) 

'(edr  (vlrt-assq  'default-certainty  (external -properties  .node)))) 

(defun  certainty  (node) 

(cond  ((unknown?  node)  0) 

((premise 7  node) 

(default-certainty  node)) 

(t  (mln-cert  (support  node))))) 

(defmacro  mln-cert  (clause) 

'(mln-cert2  *max-cert*  (clause-list  ,c1*u*9 ))) 

(defun  mln-cert2  (mln-cert  cllst) 

(cond  ((null  clist)  mln-cert) 

((not  (false-term?  (car  cllst))) 

(m1n-cert2  mln-cert  (edr  cllst))) 

(t  (m1n-cert2  (min  mln-cert  (certainty  (caer  cllst))) 

(edr  cllst))))) 

(defun  set-default  (node  value  certainty) 

(If  (not  (numberp  certainty))  (break  (non  numeric  certainty))) 

(setf  (default  node)  value) 

( setf  (default-certainty  node)  certainty) 

(premise-check  node)) 

(defun  remove-default  (node) 

(setf  (default  node)  nil) 

(If  (premise?  node)  (retract-premise  node))) 

(defun  prmcon-checker  (nodes) 

(mape  ’premise-check  nodes)) 

(defun  premise-check  (node) 

(if  (default  node) 

(cond  ((or  (unknown?  node) 

(not  (<  (default-certainty  node) 

(certainty  node)))) 

(make-premise  node  (default  node)))))) 
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(defun  prmcon-selector  (premises) 

(let  ((assums  (least-cert-premises  preailies))) 

(if  (cdr  assume) 

(user-choice  assume) 

(car  assume) ))) 

(defun  least-cert-premises  (premises) 

( least-cert-2  (list  (car  premises)) 

(default-certainty  (car  premises)) 

(cdr  premises))) 

(defun  1east-cert-2  (so-far  min-cert  rest) 

(if  (null  rest) 
so-far 

(let  ((node  (car  rest))) 

(let  ((cert  (default-certainty  node))) 

(cond  ((<  cert  min-cert) 

( 1east-cert-2  (list  node)  cert  (cdr  rest))) 

((•  cert  min-cert) 

( least-cert-2  (cons  node  so-far)  min-cert  (cdr  rest))) 
(t  (least-cert-2  so-far  min-cert  (cdr  rest)))))))) 
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7.  APPENDIX  II:  UTILITY  PROCEDURES 

Most  of  the  basic  concepts  behind  the  utilities  described  here  have  been  developed  by  various 
people  other  than  the  author  and  many  of  them  arc  documented  in  the  1  .ISP  MACHINE  MANUAL 
[Wcinrcb  &  Moon  78J. 

7.1.  Basic  Macros 

7.1.1  BACKQUOTE 

Ihe  backquote  feature  provides  a  form  of  quote  which  replaces  items  preceded  by  a  comma  with 
their  value.  Ihe  following  are  some  examples  of  die  use  of  backquote: 

'(foo  a  ,(♦  1  2))  evaluates  to:  (foo  a  3) 

'(foo  .(list  'a  ’b)  (list  ‘a  'b))  evaluates  to:  (foo  (a  b)  (list  'a  'b)) 

Items  in  the  interior  of  backquotcd  expressions  which  arc  preceded  by  ,(&’  have  their  values 
exploded  into  the  top  level  list  structure.  An  example  of  the  use  of  this  feature  is  as  follows: 

'(foo  .#( 1 1st  'a  ’b)  .(list  'a  'b)  (list  'a  ’b)) 
evaluates  to: 

(foo  a  b  (a  b)  (list  'a  * b ) ) 

7.1.2  DKFMACRO 

This  form  is  used  to  define  macros.  A  macro  definition  has  a  similar  syntax  to  a  function  definition. 
When  a  form  whose  car  is  a  macro  is  evaluated  the  macro  definition  is  used  to  generate  a  new  form  whose 
value  is  the  value  returned  for  the  original  form.  The  arguments  to  the  macro  are  bound  to  the  forms  in  the 
argument  positions  rather  than  their  values  as  is  done  for  functions.  An  example  of  a  macro  definition  is  given 
below: 


(dafmacro  first-part  (x) 

•(caar  ,*)) 

Using  this  definition  (first-part  a)  macro  expands  to:  (caar  a)  and  so  (fist-part  a)  has  the  same  value 
as:  (caar  a).  A  macro  Ls  often  used  instead  of  a  trivial  function  definition  because  it  is  expanded  within  the 
compiler  and  results  in  more  efficient  compiled  code. 

It  is  sometimes  convenient  to  allow  the  bound  variable  list  of  a  macro  to  be  an  arbitrary  list  structure 
rather  than  a  simple  list  In  this  case  atoms  in  the  bound  variable  list  (or  bound  variable  pattern,  since  it  need 
not  be  a  simple  list)  arc  bound  to  corresponding  parts  of  the  expression  using  the  macro.  For  example  the 
new  MACLISP  form  of  do  could  have  been  defined  as  a  macro  along  the  following  lines: 
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(defmacro  do  (variable-bindings  (end-test  .  end-body)  .  do-body) 

...) 

Ibe  bound  variable  list  may  also  be  a  single  atom,  in  which  case  that  atom  is  bound  to  the  entire  list 
of  "arguments"  to  the  macro. 

7.1.3  DKFMAC 

dcfmac  is  identical  to  defun  with  the  exception  that  a  macro  is  created  which  the  compiler  can  use  to 
open  code  the  function  during  the  compilation  of  other  functions.  Ibis  is  used  purely  for  reasons  of 
efficiency.  The  open  coding  is  useful  in  getting  the  compiler  (and  other  optimization  macros  such  as  dcftail) 
to  perform  optimizations  which  would  not  otherwise  be  done.  No  function  defined  via  dcfmac  can  be 
recursive  however  since  this  would  lead  to  infinite  expansion  during  open  coding. 

7.1.4  IF 


(if  a  b  c)  macro  expands  to:  (cond  (a  b)  (t  c)). 
(if  a  b)  expands  to:  (cond  (a  b)). 


7.1.5  LET 


The  let  feature  allows  structured  lambda  binding.  An  example  follows: 

(let  ((«  1) 

(b  2)) 

(*  a  b)) 

Is  equivalent  to: 

((lambda  (a  b)  (+  a  b))  1  2) 

The  let  macro  allows  the  the  bindec  of  a  binding  pair  to  be  an  arbitrary  list  structure  whose  parts  are 
bound  to  the  corresponding  parts  of  the  value  being  bound.  Ibis  is  convenient  for  dealing  with  functions 
which  conceptually  return  more  than  one  value. 

7.2.  Side  Effect  Macros 

7.2.1  SETF 


The  setf  macro  gives  a  general  method  for  side  effecting  data  structures.  Ibe  following  equivalences 
give  some  examples  of  its  use: 


(satf  i  b)  It  aqulvaiant  to: 

(satf  (got  a  b)  c) 

(satf  (car  a)  b) 

(satf  (edr  a)  b) 

(satf  (cond  (a  b)  (c  d))  a) 


(aatq  a  b) 

(putprop  a  c  b) 

(rplaca  a  b) 

(rplacd  a  b) 

(cond  (a  (satf  b  a))  (c  (satf  d  a))) 


k 


■i 
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The  self  macro  macroexpands  its  first  argument.  ITius  it  is  possible  to  use  self  in  conjunction  with 
macros  as  is  demonstrated  below. 

(defmacro  foo  (x) 

'(caar  .*)) 

(setf  (foo  a)  b)  macroexpands  to  (rplaca  (car  a)  b) 

7.2.2  DEFSIDMAC 

defsidmac  is  just  like  defmacro  except  that  it  is  used  to  define  macros  which  side  effect  their  last 
argument  and  treats  that  argument  position  specially.  Specifically  it  defines  a  macro  which  will  embed  the 
side  effect  in  conditionals  as  docs  setf.  To  sec  how  this  works  consider  the  following  definition  of  addf. 

(defsidmac  addf  (x  list) 

'(setf  .list  (cons  ,x  .list))) 

(addf  x  b)  is  equivalent  to:  (setf  b  (cons  a  b ) ) 

but 

(addf  x  (if  a  b  c))  is  equivalent  to:  (if  a  (addf  x  b)  (addf  x  c)) 

While  it  may  seem  obscure  to  write  code  which  side  effects  conditional  expressions,  the  ability  to  do 
so  can  be  important  when  data  structure  macros  expand  to  conditionals.  In  such  situations  it  is  sometimes 
convenient  to  be  able  to  side  effect  applications  of  these  macros. 

7.2.3  INCREMENT 

increment  is  defined  by: 

(defsidmac  increment  (x) 

'(setf  ,x  ( 1+  .x))) 


7.2.4  ADDF 


addf  is  defined  by: 


(defsidmac  addf  (x  list) 

’(setf  .list  (cons  ,x  .list))) 


7.2.5  DELF 


dclf  is  defined  as: 

(defsidmac  delf  (x  list) 

'(setf  .list  (delete  ,x  ,11st))) 
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7.2.6  VIRT-ASSOC 

This  function  is  like  assoc  except  that  it  is  always  guaranteed  to  return  a  cons  whose  car  is  its  first 
argument.  Furthermore  if  there  was  no  such  cons  originally  in  the  association  list  then  the  cons  returned  is 
automatically  addf d  to  the  alist.  Ihc  following  is  a  typical  use  of  virt-assoc 

(defmacro  foo  (x) 

•(car  ,x) ) 

(defmacro  other-properties  (x) 

•(edr  .x)) 

(defmacro  bar  (x) 

'(edr  (virt-assoc  'bar  (other-properties  .x)))) 

(setf  a  (cons  nil  nil)) 

(setf  (bar  a)  ’bar-val) 

;a  now  is  (nil  .  ((bar  .  bar-val))) 

;  (bar  a)  is  now  bar-val 

7.2.7  VIRT-ASSQ 

virt-assq  is  to  assq  as  virt-assoc  is  to  assoc. 

7.3.  Definition  Macros 

7.3.1  DEFSTRUCT 

The  defstruct  feature  is  used  to  define  a  type  of  structured  object.  A  dcfstruct  definition  creates  a  set 
of  macros.  One  of  these  macros  is  used  to  create  objects  of  the  defined  type.  Ihe  others  arc  used  to  access  the 
parts  of  that  object.  Consider  the  following  example: 

(defstruct  (ship)  x-pos  y-pos  (mass  200)) 

'finis  defines  four  macros:  make-ship,  x-pos,  y-pos,  and  mass.  The  make-ship  macro  creates  a  ship 
with  its  mass  set  to  a  default  value  of  200.  The  following  dialogue  illustrates  a  use  of  these  macros: 

(SETQ  HERO  (MAKE-SHIP)) 

{nil  nil  200} 

(MASS  HERO) 

200 

(SETF  (X-POS  HERO)  10) 

10 


* 


(X-POS  HERO) 
10 
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7.3.2  DHFTA1L 


When  dcftail  is  used  instead  of  defun  in  a  function  definition  tail  recursion  optimization  is 
performed  on  the  body  of  that  definition.  This  feature  actually  docs  more  than  simple  tail  recursion 
optimization  in  that  simple  accumulations  (functions  which  generate  sums,  products,  or  lists  recursively)  are 
also  convened  to  iterative  forms. 


7.3.3  DEFARB 


defarb  is  identical  to  defun  except  that  it  allows  (lie  bound  variable  list  to  be  an  arbitrary  list 
expression.  The  atoms  in  this  expression  arc  bound  to  the  corresponding  parts  of  the  list  of  values  to  which 
die  defined  is  applied.  The  most  common  use  of  defarb  is  to  have  the  bound  variable  pattern  be  a  single  atom 
in  which  case  that  atom  is  bound  to  the  list  of  arguments  to  die  function.  A  function  so  defined  can  take  an 
arbitrary  number  of  arguments. 

7.4.  Query  Functions 

7.4.1  PUSH  QUERY 


Ihis  function  takes  a  "query",  prints  a  "query  list",  and  pushes  information  on  an  internal  data 
structure  which  is  used  to  "answer"  the  query.  A  query  is  a  cons  of  an  "initial  query”  and  a  "query-list".  Ihe 
initial  query  can  be  any  s-expression  and  is  printed  as  the  first  pan  of  the  printed  query.  'Hie  query  list  is  an 
association  list  of  s-expressions  with  arbitrary  objects.  The  printed  query  consists  of  die  initial  query  followed 
by  an  enumeration  of  the  s-expressions  in  die  query  list.  The  following  example  should  be  useful. 


(push-query  (cons  '(the  items  of  interest  are) 

(list  (cons  'iteml  'answerl) 

(cons  'item2  'answer2) 

(cons  'item3  'answer3)))) 

;  which  results  in  the  following  being  printed: 

((the  items  of  interest  are) 

(1  iteml) 

(2  item2) 

(3  1tem3)) 

7.4.2  ANSWER 


Ihis  function  is  only  meaningful  after  a  query  has  been  pushed.  It  takes  a  single  numeric  argument 
and  returns  the  datum  that  was  associated  with  the  corresponding  s-expression  in  the  query  enumeration.  For 
example  assuming  die  previous  query  pushed  was  the  above  query,  the  answer  would  yield  the  following 
results: 
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{answer  1)  •>  answerl 
(answer  2)  ■>  answer2 
(answer  3)  ■>  answer3 

7.4.3  POP-QUERY 

This  function  pops  the  query  stack  such  that  further  calls  to  answer  are  computed  in  the  context  of 
an  earlier  query. 

7.5.  Mapping  Functions 

All  of  the  standard  MACLISP  mapping  functions  have  been  converted  to  macros  which 
macrocxpand  to  iterative  forms.  This  allows  one  to  map  macros  as  well  as  normal  functions,  lbcsc  macros 
also  provide  a  great  deal  of  optimization  not  normally  supplied  by  the  compiler.  For  example  embedded 
mappings,  such  as  (mape  Too  (inapeur  'bar  I)),  macro  expand  into  a  single  iterative  form.  Some  non-standard 
mapping  functions  and  special  forms  relating  to  mapping  functions  have  also  been  defined. 

7.5.1  CIRCULAR-LIST 

This  function  of  one  argument  returns  an  infinite,  self  referential  list  of  that  argument.  'ITiis  is  used 
to  create  list  arguments  to  mapping  functions.  For  example  a  list  of  symbols  could  be  set  to  nil  with  the 
following  expression: 

(mape  'set  symbols  (circular-list  nil)) 

The  mapping  macros  recognize  circular-list  arguments  and  produce  iterative  forms  which  avoid  actually 
creating  the  infinite  list 

7.5.2  I  NTF.G ERS-  BETWEEN 

This  function  of  two  numeric  arguments  returns  a  list  of  all  the  integers  between  those  arguments 
inclusive.  Thus  one  could  convert  an  array  to  a  list  with  the  following  code: 

(mapear  ’ar-1  (c1rcutar-H*t  array) 

(integers-batwaen  0  (1-  (car  (dimension  array))))) 

The  mapping  functions  recognize  intcgcrs-bctwccn  forms  and  avoid  actually  creating  such  a  list.  Also  because 
nested  mappings  arc  merged,  the  above  form  could  be  given  as  an  argument  to  a  second  mapping  function 
and  the  resulting  code  would  be  just  as  efficient  as  a  single  iteration  over  the  elements  of  the  array. 

Ihc  second  argument  to  intcgcrs-bctwccn  can  be  the  atom  inf.  Ibis  is  recognized  by  the  mapping 
functions  which  then  treat  the  intcgcrs-bctwccn  argument  as  an  infinite  list.  However  intcgcrs-bctwccn 
actually  only  creates  a  finite  list  when  given  inf  as  its  second  argument 
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7.5.3  FMAPCAR 


This  is  the  same  as  tnapear  except  that  all  null  elements  are  removed  from  the  list  returned.  Ilius: 


(fmapear  'foo  11) 
is  equivalent  to: 

(mapean  '(lambda  (*)  (list  (foo  x)))  11) 

7.5.4  FORALL 


This  could  have  been  defined  as: 


(defun  forall  (list  pred) 

(or  (null  list) 

(and  (funcall  pred  (car  list)) 
(forall  (edr  list)  pred)))) 

7.5.5  EXISTS 


This  could  have  been  defined  as 


(defun  exists  (list  pred) 

(and  list 

(or  (funcall  pred  (car  list)) 
(exists  (edr  list)  pred)))) 

7.5.6  ACCUM 


This  could  have  been  defined  as: 


(defun  accum  (fun  list  temp-accum) 

(if  (null  list) 
temp-accum 
(accum  fun 

(edr  list) 

(funcall  fun  (car  list)  temp-accum)))) 

7.5.7  LSUM,  LPROD 


These  could  have  been  defined  as: 


(defun  Isum  (list) 

(accum  'sum  list  0)) 

(defun  lprod  (list) 

(accum  'product  list  1)) 
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7.6.  Miscellaneous  Functions 

7.6.1  MERGE 

This  is  defined  as: 

(deftail  merge  (11  12) 

(cond  ((noil  11)  12) 

((member  (car  11)  12)  (merge  (cdf  11)  12)) 
(t  (merge  (edr  11)  (cons  (car  11)  12))) 

7.6.2  HASH 

This  is  a  hashing  function  on  s  expressions. 


I 
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